I've never heard of or experienced this issue before, do you have any examples where this can be reproduced?

Hello @h2zero,

Here is the minimum reproducible example (it tested it with bc333cc),
In this example, it will never print Initialized.
It got stuck inside NimBLEDevice::init(), and the NimBLEDevice was never sucessfully initialized.
And after a few seconds the system will be reset by watchdog.

#include <NimBLEDevice.h>

void InitNimbleTask(void* args)
{
    Serial.println("Initializing NimBLEDevice");
    NimBLEDevice::init("NimBLE-Arduino");
    Serial.println("Initialized");

    NimBLEDevice::startAdvertising();

    vTaskDelete(NULL);
}

void setup() {
    Serial.begin(115200);

    // host_task has priority (configMAX_PRIORITIES - 4)
    const uint32_t priority = (configMAX_PRIORITIES - 3); 

    // host_task is pinned at core 0
    xTaskCreatePinnedToCore(InitNimbleTask, "InitNimbleTask", 8192, NULL, priority, NULL, 0); 
}


void loop() {

}

As stated in the PR, I think it's because host_task has priority (configMAX_PRIORITIES - 4)

And if we set the priority of InitNimbleTask to (configMAX_PRIORITIES - 4) or lower, it works again.

Some even trickier situation,

1. If we add a print in the problematic loop
   

   NimBLE-Arduino/src/NimBLEDevice.cpp

   Lines 909 to 911 in bc333cc

   	while(!m_synced){
   	taskYIELD();
   	}

   while(!m_synced){
       Serial.println("YIELD");
       taskYIELD();
   }

   It works again!
   This is because Serial.println() make the NimBLEDevice::init() task go to block state, which gives host_task some time to be executed.

2. If we don't pin InitNimbleTask at core 0
   If we created the task with xTaskCreate instead of xTaskCreatePinnedToCore, it magically works.

   const uint32_t priority = (configMAX_PRIORITIES - 3);
   xTaskCreate(InitNimbleTask, "InitNimbleTask", 8192, NULL, priority, NULL);

   But if we change the priority to (configMAX_PRIORITIES - 2) or (configMAX_PRIORITIES - 1), it gets stuck again.

   const uint32_t priority = (configMAX_PRIORITIES - 2);
   xTaskCreate(InitNimbleTask, "InitNimbleTask", 8192, NULL, priority, NULL);

   I don't really know the reason behind, but I guess maybe it's because ESP32 has 2 cores, so the host_task may not be starved.

Due to the nature of the BLE stack I would highly recommend using a task priority for the application that is less than the host task. Is there a specific purpose to have your application run at a higher priority than the host task?

Due to the nature of the BLE stack I would highly recommend using a task priority for the application that is less than the host task. Is there a specific purpose to have your application run at a higher priority than the host task?

Actually, I don't really need the priority of application be higher, I just accidentally found this problem when I set different task priority for my application.
I was porting this project to an MCU (other than Arduino, ESP32), and it uses polling to read user command from UART, one of the UART command is to turn BLE on.
To make the UART command handler be as responsive as possible, I made its priority the highest configMAX_PRIORITIES - 1, then I found when I launch NimBLEDevice::init() inside this command handler, which has the highest priority, it gets stuck.

@CW-B-W That is a great explanation, thank you for this. I have tested your example and propose a different fix.

Instead of the semaphore, could you just replace the taskYIELD() in the while loop with ble_npl_time_delay(1) instead, that should resolve the issue as well without the extra memory requirements.

Came here to say I've also independently found this issue

FYI I tried to use ble_npl_time_delay(1) I even went so far as making m_synced volatile. Doesn't work for me

Doesn't look like the patch works for me either. xSemaphoreTake never returns.

So after a lot of debugging it looks like one of my own tasks starving resources from NimBLEDevice. From the comments it looks like this lib doesn't need to create it's own task. I'd love to know how to implement this.

@i-am-shodan you shouldn't need to do anything other that add a call to delay() in your own tasks/loop, this allows for a context switch.

I'm also experiencing crashes due to starvation of the host task.
I have to paly with the priority of several tasks in my code to make it "work", but it is fragile.
I'm working on a reduced test case.

Is there a reason not to merge thechange proposed in #584 (comment) ?? This change looks good to me.

Unless you have a very good reason to have any tasks with priority higher than the BLE host task then you should make sure that everything else is lower priority.

Is there a reason not to merge thechange proposed in #584 (comment) ?? This change looks good to me.

No reason, just haven't got to it yet 😄

Yes, there is a lot of things going on in the BLE stack and it needs time to process.